約 4,643,571 件
https://w.atwiki.jp/soreiro/pages/302.html
Valentine s Day Event 2013 目次 ◆ 概要 ◆ Costume Cake hat quest ◆ Orc Woman's Rage event ◆ Incubus/Succubus quest◆ Monster List ◆ 概要 期間 イベント 外部リンクなど 2/12～3/12 [R/C] Valentines event [C R] True love awaits with our Valentines Day events! -Event 2/26?～3/12 Costume Cake hat quest Costume Cake Hat Event this weekend! -News どちらも、3/5→3/12 までに延長 Valentines event 公式の記事 ▼ [C&R] True love awaits with our Valentines Day events! -Event ※ 更新あり Events 2/12/2013 真の愛が私たちのバレンタインデーのイベントでお待ちしてます ロマンチックな休日に、複数のクエスト、ショップアイテムとダブルEXP が、ルーンミッドガルドの世界に登場 いくつかのイベントで、このロマンチックな伝統を尊重します！ monster drops and experience rewards は、2/12～26 first Valentine’s day quest では、復讐心に燃えた Orc Lady の呪いから、愛のカップルを守ります。このクエストは、新しい休日をテーマにしたヘッドギアとロマンチックなお菓子が報酬です。 ( a new holiday themed headgear as well as romantic candies ) players level 20 ↑なら、Geffen の the wizard Valentine(120, 98) と会話で開始。報酬は festive headgear second questでは、lovestruck fairyがインキュバスとの愛情の接続を行うのを助けます。レベル制限はありませんが、abyss lake 1 への旅行を伴わないことは注意して使用してください！(※ 伴う？) Hyllis in Comodo と会話で開始。クエストの報酬は、expの塊です。repeatable で、VIPが１２時間、non-vip が２４時間です これらのクエストは3週間にわたって実行し、楽しいヘッドギアの報酬が含まれています！ 今月はたくさんのイベントがありますので、フォーラムやサイトから目を離せない！ これらのクエストに加えて、リニューアルとクラシックの両方に Groove pack を追加 参考Valentine's Day Event (2013-02-12~2013-02-26) - iRO Wiki Cake Hat 関係の話題Cake Hat (Costume Headgear) -iWdb 2012 Valentine's Day Event - iRO Wikiこれの (Quest 1) が実装されてる？ Cake Hat (Costume Headgear)がもらえるらしい Cake Hat - Public Service Announcement -Forums (Started by Dreimdal, Feb 27 2013) Making Cake Hats -Forums (Started by Helios0, Feb 08 2012) Headgear Ingredients - iRO Wiki ▼ 2/26 Tex Avery s Birthday maintenance -Forums Forums 更新あり。追加項目 +Costume Cake hat quest from last year s Valentines day event will be in for one week for those looking to make one. ( 昨年のバレンタインのイベント由来で、Costume Cake hat quest が１週間 ) #209 Oda (2/27) Since the costume cake hat quest was put in, the enriched event was extended just until next week when the cake hat quest leaves. ▼ Costume Cake Hat Event this weekend! -News News 03/01/2013 モスコビアの非常に甘～いチョコレート大好きなクレイジーギャルのクエストです！ +8 cake hat を用意すると、SP+60 になっちゃうコスチュームバージョンに交換してくれます！ Check out the iROwiki guide for doing the quest Valentine s Day Event (Quest 1) After the maintenance, we will have a special NPC in the Eden group next to Primo D Buffer that will give a daily drop rate buff to players who completed the quest and are wearing the costume hat! If you completed the quest last year, you will still be able to get the buff, but your characters must have completed the quest in addition to be wearing the hat! ( メンテ後、このコスをかぶると毎日のドロップ率のバフを与える特殊NPCが登場します。去年のクエストを完了した場合でも、バフを得ることができますが、帽子をかぶっていることに加えて、クエストを完了している必要があります！) ◆ Costume Cake hat quest タイトル Costume Cake hat quest レベル制限 ４５ 前提 なし 必要アイテム +8 Cake Hat、15x Stolen Cacao 報酬 Exp 500K/400K ( VIP 750K/600K )？ 報酬 その他 Costume Cake hat (Headgear) その他。(お菓子交換可能に？) 備考 2012 Valentine s Day Event から、再実装 備考 3/5～ に特殊NPCが登場してドロップ率のバフをくれる 手順 作業中です in the tool shop (moscovia 222, 176) Pinkamenia(mosc_in 21,246) と会話 help her. She will tell you to bring a +8 Cake Hat to the Baker Extraordinaire you can hunt the Stolen Cacao. Cake Hat は、ルティエで作成して、自力で＋８にして持参する 隣の Baker Extraordinaireと会話 to get the Cake Hat (Costume Version). Notethat having a Cake Hat (Costume Version) is entirely optional, provided you can get the Stolen Cacao required. Hunt 15 Stolen Cacao while wearing the Cake Hat (Costume Version) (or purchase it from other players) and return back to Pinkamenia. She will reward you with 500K/400K ( VIP 750K/600K ) バフのNPC。帽子なしだと反応なし ※ 3/5 当初は、Eden１階で別のキャラだったが、移転・別キャラに Costume Cake hat buff NPC will be added to Outside Prontera tool shop, this NPC will give a daily buff for those who completed the cake hat quest and are wearing a costume version of the hat. ◆ Orc Woman s Rage event タイトル Orc Woman s Rage レベル制限 ２０ 前提 なし 必要アイテム なし 報酬 Exp なし 報酬 その他 Sweet Valentine (Headgear) または粗品がランダムで 備考 repeatable で、２０時間 (VIPは不明ｗ) 粗品＞5x Handmade White Chocolate, OR 5x Hand-made Chocolate, OR 10x Chocolate, OR 10x White Chocolate 配達後のクエスト表の不具合は、2207 2013-2-14 パッチで改修 手順 作業中です Geffen の the wizard Valentine(120, 98) と会話で開始 5x Love Wand をもらう Broken Hearted Woman を見つけて会話 5x Love Wand を配っていく Use すると、Woman in love になる ランダムに、Sweet Valentine (Headgear) または 5 White Chocolate + 5 Random chocolate をくれる5x Love Wand を配った後は、２０時間待ち （※ なんか、Orc Woman を待ち構えて みんなで叩きのめしていましたが？ ） Sweet Valentine (Headgear) スペックはこちら。3/5 まで効果 blankimgプラグインエラー：ご指定のファイルがありません。アップロード済みのファイルを指定してください。 ◆ Incubus/Succubus quest タイトル Fae Crossed Lovers レベル制限 なし 前提 なし 必要アイテム 花束( Bouquet )、聖水 ハント 20x Ferus (Green)、20x Ferus (Red) 報酬 Exp [R] 150K/150K 他、VIP は 1.5倍 報酬 その他 Girl s Naivety (2)、Boy s Pure Heart (2) 備考 repeatable で、VIPが１２時間、non-vip が２４時間 abyss lake 1 へ自力で出直す場合は、通常アクセス用のしかるべきアイテム 手順 First Flight Hyllis has asked you to take a letter to the mystical mailbox on the Comodo Docks Hyllis と会話で開始 in Comodo (65, 344) 辺り (※ 画像のLilith (Succubus)は、誰かの進捗によって見えたり見えなかったり) Mystic mailbox at the harbor へデリバリー カプラから南へ桟橋を歩くと見つかる Flower Power Alp has requested you bring a bouquet to Hyllis for him. 会話すると、Alp(Incubus)が現れて会話が進行 Hyllis に花束( Bouquet )を送るように頼まれる Mail Man Hyllis has asked you to take a letter to the mystical mailbox on the Comodo Docks Hyllis に用意した花束を与え、また別の手紙を届けに行く Succubi Lilith has tossed you into Abyss Lake Dungeon, she hinted that Alp is down here somewhere on this level.You should try to find Alp mystical mailboxと会話で、 abyss lake 1 へ送られる (succubi は、succubusの複数形らしい ) Incubi Alp has asked you to kill 20 of each Ferus to clear the way for him. He will meet you in the Comodo Casino once you are done.Alp を見つけて会話 (209,145) kill 20x Ferus (Green)、20x Ferus (Red) を要求されるので、倒す (途中で死んだりで戻った場合は、自力で出直す) 終わったら、コモドへ戻る カジノの中で、Alp と会話 (167,106 )辺り Fairy Dust Alp said to bring Holy Water with you and to talk to Hyllis. He is afraid that Lilith will try to interfere. Hyllis と会話で進行 誰に聖水をかけるか選べ的な質問に答える 報酬をもらう ※ 中段 Lilith (Succubus) ※ スレ情報コミで、選択上中下で、VIP＞150k/150k、225k/225k（テイム）、70k/70k （プロンテラに飛ばされる）※ 聖水は持参か会話上なのか未確認。たまたま持参→wikiでは必要アイテム Please wait 24 hours before repeating the quest または Please wait 12 hours before repeating the quest ◆ Monster List Monster Lv HP Base Job Race Attribute Hit Flee Ferus (Green) 126 39,054 4,185 2,989 Dragon Earth 2 383 383 Ferus (Red) 126 25,668 3,985 2,989 Dragon Fire 2 406 405
https://w.atwiki.jp/tasy2/pages/17.html
素早さと行動順の関係 ★戦闘時の素早さの真値 素早さに依存しないランダム部分A 素早さに依存するランダム部分B 真値の分布 ※AGI80の場合 ★戦闘時の素早さの真値 値＝素早さに依存しないランダム部分A)＋(素早さに依存するランダム部分B) 結果は整数。同値の場合は味方1側が優先。(※ちなみにPS2DQ5は敵最後尾が優先) 素早さに依存しないランダム部分A 素早さが0であっても、真値が1～16前後の数値を取ります。 256個サンプリングして、平均は10.4程度。 中央が尖っている分布なので、0-8を2個 →0-5を3個 →0-4を4個 →0-3を5個……と 分布が一致するパターンを模索します。Excelさんが頑張ってくれます。 平均値が中央より上にあるので、ゲタを履かせて調整を。 ★素早さに依存しない部分の分布 ※系列1が実測値分布、系列2が計算値。下図のメモリは作業上の仮値 ランダムA(avg)＝MOD(乱数1,4)＋MOD(乱数2,4)＋MOD(乱数3,4) ＋MOD(乱数4,4)＋MOD(乱数5,4)＋MOD(乱数6,4)＋1.5 素早さに依存するランダム部分B ★素早さに依存する部分の分布 ランダムB(avg)＝MOD(乱数7,AGI/4)＋MOD(乱数8,AGI/4) ＋MOD(乱数9,AGI/4)＋MOD(乱数10,AGI/4)＋1.0 ※AGI=80なら、0-19の4項分布。端数処理の帳尻合わせの関係で、1.0を足しています 真値の分布 ※AGI80の場合 簡単に纏めると、真値の期待値は『AGI÷2＋9』です。
https://w.atwiki.jp/cod4opoona2ch/pages/15.html
DOMTIPS miazouさん、wryさん、あとDOMが得意な人、加筆修正おながいしまつ＞＜ 不利旗一覧 Backlot ABキープが理想。 無理ならAorCを取って敵の気を引こう。 Broadcast リスポンの関係上、A付近の建物で芋らなければACもアリ。 ひょんなことでAにリスポンが移って戦線復帰に時間が掛かることもあるので、可能な限りBC狙い。 ACなら、C奥階段上を必ずキープすること。 BCで、B北の部屋の奥に行きすぎるとCを取られるので注意。 Crash A建物で芋ると押し込まれる。 Aへの押し込みは、A-C間の壊れた車のある裏通りからのCへの接近に要注意。 Cで押し込まれたら、まずはB隣の屋上付きの建物を占拠。 Crossfire B正面のC寄りの建物は必ず占拠すること。 A2ヶ所の建物でのキャンプは厳禁。 District オ鯖名物回遊魚水族館へようこそ Overgrown AC鉄板。B奥ガソリンスタンドまで追い込めば、全旗取っても維持可能。 B奥ガソリンスタンドには近づかないように。 Pipeline 若干Aが不利か。Bは必須。 C屋根上やA-C間の奥のブッシュに行き過ぎると、リスポンが著しく不利になる。 Strike BC維持も可能だが、CやC-A間の建物で芋るとBを取られてしまう。 Bは、B西の水場(?)辺りをクリアしてからだと取りやすい。 Vacant 左右のバランスを崩さないようにCへ押し込むこと。 Cに押し込まれてしまったら、一気に西側倉庫を突破してA外にリスポンを移すか愚直にBを取る。 Aに押し込まれてしまったら、B東の外の車が見える辺りまで押し返してからBを取る。 西倉庫からCは最悪。 旗取るのにかかる時間 10秒/旗取ろうとしている人数 二人なら5秒 3人なら3.3秒・・・ 敵に気づかれていない状態の裏取りから旗をとる場合は 最低二人いると取れる確率が上がる。 スモーク炊いた状態での旗鳥阻止はほとんどがグレネードによるものであり COD4のグレネードの爆発までの時間はボタンを押してから信管を抜くまで約0.5秒 信管抜いてから4秒で爆発なのでアナウンスや旗マークの点滅を見てからだと間に合わない。 またアナウンスを消したりするにはUAVを発動させた瞬間に旗を取る など 他のアナウンスにかぶせると旗鳥アナウンス自体が消えたり遅れたりする。 さらにポイントとして旗鳥ゲージは旗本から一瞬はなれただけではリセットされない。 グレネードが旗本中央に落とされない限り爆発のタイミングにあわせて 旗から一瞬はなれる＞戻るといった行動で死なずにゲージ継続も慣れれば案外できる。 また死んで倒れる間も一瞬ゲージ溜め判定が残っているのかどうかわからないが 死んでから旗を取れることも多々ある。 小ネタとしてpark3のラストスタンド状態でもゲージ継続となる。 ラストスタンド状態移行中は無敵状態となるので少しの間ゲージを溜めることができる。 crossfire ttp //up2.viploader.net/pic/src/viploader925640.jpg とりあえず初動A取っても大差ないと思ってる 問題はBをどちらが先に取るか。フラグの雨あられをかわして行くしかない ただし初動（1分ぐらい？）の範囲を超えるとC側有利になり始める。 フラグ投げられる範囲があまりにも違うので初動で取れなかったらC側が取る可能性が高い。 で被レイプ時 C取ってAB取られレイプはそのうちリスポンが黄色、水色、と移動していくので大してレイプ感は無い。 レイプ側がCに集中しているとピンク点からBを取れることも。 問題なのはAとって水色をBC側に抑えられた状態 リスポンがMAP最奥の黄緑辺りに移る。 この状態はどうしようもない。とにかくスモーク投げてBへのルート確保か水色奪還。 最低限紫ラインを保っての被レイプならBとCを交互に攻める感じで相手を揺らす。 Cに行く時に大通りを通らないといけないので青点とかに相手の上手い砂いる場合はオレンジにスモーク 一個では足りないかも このMAPは被レイプ時とにかく大人数で固まって攻めないと無理 後フラグルート1が凶悪すぎる。C取ろうとしているのが一人なら簡単に殺される。 jam持ちと非jam持ちで分かれて分隊行動とか出来れば面白いんだけどね 後、C行く場合はjam持ってると取った後の防衛も楽 ここまで書いて何だけどBC保持レイプ側が連携上手く取ってみんな動けばどうしようもない。
https://w.atwiki.jp/stalker_cop/pages/170.html
MOD - その他 小物系など細々としたMODはここにまとめました。 MOD - その他実銃名化 CoPロシア版の英語化MODCall Of Pripyat - English Translations Patch Better English Translation Call of Pripyat FULL English Translaition Russian to English Speech DataBase S T A L K E R - Call Of Pripyat Spawn Mod Realtime mod Visible range mod Loot Money From Corpses Shadow of Pripyat AI Additions FOV switcher 1.7 実銃名化 銃の名前を実際のものと同じに変更します。英語版、日本語化mod共に対応。 http //u4.getuploader.com/stalker/download/194/CoP+realgunname+v3.zip CoPロシア版の英語化MOD ロシア版のCoPを使用している人向けのMOD。日本語化も出ている今となってはあまり必要ないかも。 Call Of Pripyat - English Translations Patch Google翻訳も使いながらとりあえず英語化してみた、くらいのMOD。 ロシア語や半端な翻訳が結構残ってます。 http //stalker.filefront.com/file/Call_Of_Pripyat_English_Translations_Patch;104379 Better English Translation ↑をベースに全体的に手を入れた感じ。 http //stalker.filefront.com/file/Better_English_Translation;105219 現在進行形で作業が進んでいて、最新版は↓から、とのこと。 http //code.google.com/p/s-cop/downloads/list ↑こちらにはlocalsation.ltxが含まれておりどの言語版でも上書きだけで使用可能。また字幕MODや一部のテクスチャも交換される。 Call of Pripyat FULL English Translaition （xmlファイルベースで言えば）全対応済み。 アップグレード関係あたりに未訳が残っているそうです。 http //stalker.filefront.com/file/Call_of_Pripyat_FULL_English_Translaition;105893 ↑一部テクスチャも交換される。 Russian to English Speech DataBase こちらは英語の音声ファイル（75%対応）だそうです。要確認。 http //stalker.filefront.com/file/Russian_to_English_Speech_DataBase_Localization;108905 S T A L K E R - Call Of Pripyat Spawn Mod クリック1発で目の前に色々なものを"Spawn"させます。 装備、アーティファクトからNPCやミュータントも出せるようです。 自作MODや翻訳のチェック、俺TUEEEプレイのお供に。↓リンク切れです。直接modの名前で検索した方がいいです。 http //stalker.filefront.com/file/S_T_A_L_K_E_R_Call_Of_Pripyat_Spawn_Mod;107151 使用方法： 1.導入したら、プレイ中にESCを押してメインメニューに 2.Sを押すと専用メニューが開くので、出したいものをクリック ※クリック1回で1個出ます。押し過ぎに注意。 ※ToActorはプレイヤーのインベントリにSpawnさせるためのスイッチです。 ※ToActorがオンの時にミュータントやNPCを出すとCtDします。 3.Createを押した後、Closeを押すと足元もしくはインベントリにSpawnしているはずです。 Realtime mod 時間の流れる速さをリアルタイム(1 1)に。 ゲーム中にデフォルトの速さ(5 1)との切り替えも行えるようです。 http //stalker.filefront.com/file/RealTime_mod;109201 Visible range mod 視界を3倍にし、遠景にはそれなりのエフェクトを掛けます。 特にFPSが激減するような事は無いそうです。 http //stalker.filefront.com/file/Visible_range_mod;108895 Loot Money From Corpses 死体から現金を入手できるMod。 http //www.megaupload.com/?d=YTEQX0IW Shadow of Pripyat http //stalker.filefront.com/file/Shadow_of_Pripyat;111141 SoC、CSから20以上の銃・アーマーを追加。 NPCが持っていたり、トレーダーが販売したりするようです。 その他細かい変更も幾つかあるようです。 AI Additions ttp //dump.ru/file/3574139 NPCのAIに幾つかの要素を追加します。 怪我をしたら包帯を巻いたりMedkitを使用。自分だけでなく味方にも 距離によって武器を持ち換える、アドオンを付け外しする ライフルグレネードを発射する 射線を味方が塞いでいる場合は移動する ※環境・状況・マージするModによってはパフォーマンスの低下が激しくなります。 ltxファイルを弄って機能をON/OFFすればいくらか改善されるかもしれません。 ↑のリンクが切れていた場合は下記のアドレスから。 ttp //dump.ru/user/Rulix/ FOV switcher 1.7 http //www.mediafire.com/?z2dstvcrtlbc8l8 xrgame.dllを改変しFOVを変更する。 元のxrgame.dllはバックアップしておくこと。 cmdファイルを起動し、プリセットを選択する。
https://w.atwiki.jp/sizukudrop/pages/63.html
画像 http //www.geocities.jp/pencil922001/IMG_2315_0001.jpg 材料 ①G3 ②HYPER JELL ③SUPER GLIP ④Signo 作り方 １、G3のペン尻にHYPER JELLのグリップをとってつける。 ２、（１）のグリップの上からG3のキャップをつける。 ３、G3のペン先にSUPER GLIPのグリップをつける。 ４、（３）のグリップの先にsignoのチップをつける。 完成
https://w.atwiki.jp/gienkin311/pages/54.html
ソフトバンク孫氏 個人で義援金１００億円 http //www.softbank.co.jp/ja/news/press/2011/20110403_01/ 福本伸行、被災者に3000万円を寄付「絶対に負けないっ!!」 http //news.livedoor.com/article/detail/5460084/ 神田うの 新作ドレスの売上から義援金寄付 http //ameblo.jp/unokanda/entry-10847632994.html デルピエロが「友」Ｔシャツ売上金を寄付 http //news.livedoor.com/article/detail/5462405/ ミスチル新曲４日から緊急配信 収益全て寄付 http //news.livedoor.com/article/detail/5462421/ パナソニックグループ、追加支援として懐中電灯4万個を4月1日に出荷 http //panasonic.co.jp/corp/news/official.data/data.dir/jn110331-3/jn110331-3.html Nabowaが被災者支援チャリティシングルをCD＆配信で発表 http //news.livedoor.com/article/detail/5461677/ 奥尻町長が宮城など訪問し、義援金寄付 http //sankei.jp.msn.com/affairs/news/110402/dst11040217190025-n1.htm ジャッキー・チェンさんらがチャリティーイベント 約2億円の寄付集まる http //www.fnn-news.com/news/headlines/articles/CONN00196504.html
https://w.atwiki.jp/customcombo/pages/5.html
Ultimate Marvel vs Capcom 3 XBOX360 使用 予選は3人or4人のリーグ戦で上位2人が予選通過。 予選1位は決勝TのWinners、2位はLosersに。 決勝T 8人でのトーナメント戦。 全ての試合は2試合先取で実施。 試合開始前に双方ともに使用キャラを審判に申告する。 試合中の敗者側はキャラ変更可。勝者側はキャラ変更不可。（アシスト含む） ただし、アシストボタン長押しによる先鋒の変更は可。 試合中にポーズボタンを押した場合、押した側のプレイヤーが1試合取られた扱いとする。 ただし、勝ち確定状況の場合はそのまま続行する。 ステージはボーンワンダーランドか、トレモステージの選択をお願いします。 ボタンチェック（キーコンフィグチェック）の時間を取ります。 キーコンフィグはOKです。連打キーは使用禁止。 持参したコントローラーの使用は可能ですが、改造されているのは不可。 1P、2Pは試合前にじゃんけんで決定。 進行を妨げるバグ以外は全てOKです。 試合開始前の呼びかけから3分以内に集まらなかった場合不戦敗とする。
https://w.atwiki.jp/keimodwiki/pages/11.html
概要 名前 けいさんのMod前提 (Kei s Core Mod) 概要 けいさんのModの前提です バージョン 1.7 ダウンロード 1.7 最新 ver.1.0.2β +旧 旧 1.0.1β 1.0.0β 1.0.1α 1.0.0α アップデート内容 1.0.2β 2019/06/12 18 30 修正 名前がitem.名前.nameやtile.名前.nameになっていたのを修正 1.0.1β 2019/06/12 18 19 修正 ブロックのモデルが反映されていなかったので修正 1.0.0β 2019/06/12 17 55 追加 ブロックの追加 その他 β版に突入 1.0.1α 2019/06/11 19 42 追加 アイテムを追加 1.0.0α 2019/06/10 19 50 追加 アイテムを追加 その他 Mod製作開始
https://w.atwiki.jp/code_matome/pages/40.html
3.3.2. Transform Substructure 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) or 3 | RESERVED | Transform Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transform Type | RESERVED | Transform ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Transform Attributes ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 Transform Substructure o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the last Transform Substructure in the Proposal. This syntax is inherited from ISAKMP, but is unnecessary because the last transform could be identified from the length of the proposal. The value (3) corresponds to a payload type of Transform in IKEv1, and the first four octets of the Transform structure are designed to look somewhat like the header of a payload. Proposalの最後のTransform Substructureであることを示す。このシンタックスはISAKMPから継承されている。ただし、最後のtransformはproposal lengthから特定できるため不要である。3はIKEv1におけるTransformのpayload typeで TransformはProposalのlengthから特定できるため不要である。3はIKEv1のTransformのpayload typeに対応し、Transform structureの最初の4オクテットがpayload headerになるように設計されている。 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 0で送信し、受信側は無視すること。 Kaufman, et al. Standards Track [Page 79] RFC 5996 IKEv2bis September 2010 o Transform Length - The length (in octets) of the Transform Substructure including Header and Attributes. HeaderとAttiributeを含むTransform Substructureのオクテット長。 o Transform Type (1 octet) - The type of transform being specified in this transform. Different protocols support different Transform Types. For some protocols, some of the transforms may be optional. If a transform is optional and the initiator wishes to propose that the transform be omitted, no transform of the given type is included in the proposal. If the initiator wishes to make use of the transform optional to the responder, it includes a transform substructure with Transform ID = 0 as one of the options. このTransformで指定されるTransform type。異なるprotocolは異なるTransform Typeをサポートする。いくつかのProtocolにおいては、Transformはオプションである。Trasnsformがオプションで、initiatorが省略するtransformを提案する場合、TransfromのTypeはProposalに含まれない。initiatorはresponderにオプションのTransformを使用することを示すため、オプションの一つとしてTransform ID=0のTransform Substructureを含める。 o Transform ID (2 octets) - The specific instance of the Transform Type being proposed. 提案されたTransform Type。 The Transform Type values are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Transform Typeを下記に示す。下記はRFC4306発行時のものである。以降に追加された値は[IKEV2IANA]参照。 Description Trans. Used In Type ------------------------------------------------------------------ Encryption Algorithm (ENCR) 1 IKE and ESP Pseudorandom Function (PRF) 2 IKE Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP Diffie-Hellman group (D-H) 4 IKE, optional in AH ESP Extended Sequence Numbers (ESN) 5 AH and ESP (*) Negotiating an integrity algorithm is mandatory for the Encrypted payload format specified in this document. For example, [AEAD] specifies additional formats based on authenticated encryption, in which a separate integrity algorithm is not negotiated. このドキュメントにおいて、Integrity algorithmをネゴシエーションすることはEncrypted paylaodを指定する場合、必須である。例えば、[AEAD]では独立したintegrity algorithmはネゴシエーションされず、認証された暗号化方式に基づき、追加のフォーマットを指定する。 For Transform Type 1 (Encryption Algorithm), the Transform IDs are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Transform Type 1(Encryption Algorithm)におけるTransform IDは下記である。下記はRFC4306をもとにしており、最新の値は[IKEV2IANA]にある。 Kaufman, et al. Standards Track [Page 80] RFC 5996 IKEv2bis September 2010 Name Number Defined In --------------------------------------------------- ENCR_DES_IV64 1 (UNSPECIFIED) ENCR_DES 2 (RFC2405), [DES] ENCR_3DES 3 (RFC2451) ENCR_RC5 4 (RFC2451) ENCR_IDEA 5 (RFC2451), [IDEA] ENCR_CAST 6 (RFC2451) ENCR_BLOWFISH 7 (RFC2451) ENCR_3IDEA 8 (UNSPECIFIED) ENCR_DES_IV32 9 (UNSPECIFIED) ENCR_NULL 11 (RFC2410) ENCR_AES_CBC 12 (RFC3602) ENCR_AES_CTR 13 (RFC3686) For Transform Type 2 (Pseudorandom Function), the Transform IDs are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Transform Type 2(Pseudorandom Function)におけるTransform IDは下記である。下記はRFC4306をもとにしており、最新の値は[IKEV2IANA]にある。 Name Number Defined In ------------------------------------------------------ PRF_HMAC_MD5 1 (RFC2104), [MD5] PRF_HMAC_SHA1 2 (RFC2104), [SHA] PRF_HMAC_TIGER 3 (UNSPECIFIED) For Transform Type 3 (Integrity Algorithm), defined Transform IDs are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Transform Type 3(Integrity Algorithm)におけるTransform IDは下記である。下記はRFC4306をもとにしており、最新の値は[IKEV2IANA]にある。 Name Number Defined In ---------------------------------------- NONE 0 AUTH_HMAC_MD5_96 1 (RFC2403) AUTH_HMAC_SHA1_96 2 (RFC2404) AUTH_DES_MAC 3 (UNSPECIFIED) AUTH_KPDK_MD5 4 (UNSPECIFIED) AUTH_AES_XCBC_96 5 (RFC3566) For Transform Type 4 (Diffie-Hellman group), defined Transform IDs are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Transform Type 4(Diffie-Hellman group)におけるTransform IDは下記である。下記はRFC4306をもとにしており、最新の値は[IKEV2IANA]にある。 Kaufman, et al. Standards Track [Page 81] RFC 5996 IKEv2bis September 2010 Name Number Defined In ---------------------------------------- NONE 0 768-bit MODP 1 Appendix B 1024-bit MODP 2 Appendix B 1536-bit MODP 5 [ADDGROUP] 2048-bit MODP 14 [ADDGROUP] 3072-bit MODP 15 [ADDGROUP] 4096-bit MODP 16 [ADDGROUP] 6144-bit MODP 17 [ADDGROUP] 8192-bit MODP 18 [ADDGROUP] Although ESP and AH do not directly include a Diffie-Hellman exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange, providing perfect forward secrecy for the generated Child SA keys. ESP/AHはDiffie-Hellman exchangeが含まれていないが、Diffie-Hellman groupはChild SAのためにネゴシエーションされる。これは、生成されたChild SA keyにforward secrecyを提供し、CREATE_CHILD_SA exchangeにおいてpeerがDiffie-Hellmanを使うことを可能とする。 For Transform Type 5 (Extended Sequence Numbers), defined Transform IDs are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Transform Type 5(Extended Sequence Numbers)におけるTransform IDは下記である。下記はRFC4306をもとにしており、最新の値は[IKEV2IANA]にある。 Name Number -------------------------------------------- No Extended Sequence Numbers 0 Extended Sequence Numbers 1 Note that an initiator who supports ESNs will usually include two ESN transforms, with values 0 and 1 , in its proposals. A proposal containing a single ESN transform with value 1 means that using normal (non-extended) sequence numbers is not acceptable. ESNをサポートするinitiatorは、通常、Proposalに2つのESN Transform 1、0が含まれることに注意せよ。1のESN Transformのみ含むProposalはnon-extended sequence numberを許可しないことを示す。 Numerous additional Transform Types have been defined since the publication of RFC 4306. Please refer to the IANA IKEv2 registry for details. RFC 4306の発行後、多くのTransform Typeが追加された。詳細は[IKEV2IANA]参照。 3.3.3. Valid Transform Types by Protocol The number and type of transforms that accompany an SA payload are dependent on the protocol in the SA itself. An SA payload proposing the establishment of an SA has the following mandatory and optional Transform Types. A compliant implementation MUST understand all mandatory and optional types for each protocol it supports (though it need not accept proposals with unacceptable suites). A proposal MAY omit the optional types if the only value for them it will accept is NONE. SA payloadのTrsnform Typeと数はSAのプロトコルに依存する。SAの確立を提案するSA payloadには必須/オプションのTransform Typeがある。準拠した実装では、実装がサポートするプロトコル毎の必須/オプションを識別する必要がある（許容できないsuiteのproposalは許可する必要はない）。唯一許容する値がNONEの場合、ProposalのOptional Typeを省略してよい。 Protocol Mandatory Types Optional Types --------------------------------------------------- IKE ENCR, PRF, INTEG*, D-H ESP ENCR, ESN INTEG, D-H AH INTEG, ESN D-H (*) Negotiating an integrity algorithm is mandatory for the Encrypted payload format specified in this document. For example, [AEAD] specifies additional formats based on authenticated encryption, in which a separate integrity algorithm is not negotiated. このドキュメントにおいて、Integrity algorithmをネゴシエーションすることはEncrypted paylaodを指定する場合、必須である。例えば、[AEAD]では独立したintegrity algorithmはネゴシエーションされず、認証された暗号化方式に基づき、追加のフォーマットを指定する。 3.3.4. Mandatory Transform IDs The specification of suites that MUST and SHOULD be supported for interoperability has been removed from this document because they are likely to change more rapidly than this document evolves. At the time of publication of this document, [RFC4307] specifies these suites, but note that it might be updated in the future, and other RFCs might specify different sets of suites. 相互運用性とドキュメントが変化する可能性がある関係で必須のsuiteは規定しない。このドキュメント発行時点ではRFC4307に基づくsuiteを規定するが、将来更新され他のRFCの異なるsuiteが規定される可能性があることに注意せよ。。 An important lesson learned from IKEv1 is that no system should only implement the mandatory algorithms and expect them to be the best choice for all customers. IKEv1から学んだ重要なことは、必須のアルゴリズムのみを実装しており、れが全ての顧客が最も期待しているというシステムはないことである。 It is likely that IANA will add additional transforms in the future, and some users may want to use private suites, especially for IKE where implementations should be capable of supporting different parameters, up to certain size limits. In support of this goal, all implementations of IKEv2 SHOULD include a management facility that allows specification (by a user or system administrator) of Diffie- Hellman parameters (the generator, modulus, and exponent lengths and values) for new Diffie-Hellman groups. Implementations SHOULD provide a management interface through which these parameters and the associated Transform IDs may be entered (by a user or system administrator), to enable negotiating such groups. IANAが将来transformを追加し、private suiteとしてユーザーが使用することができ、特定のサイズ制限内でIKEの実装はそれらのパラメータをサポートすることができる。この目的のため、IKEv2の実装では新しいDiffie-Hellman groupのDiffie-Hellman parameters(the generator, modulus, and exponent lengths and values)を設定できる（ユーザー or システム管理者により）管理機能を含めるべきである。実装ではそのようなgroupのネゴシエーションが可能なように、parameterと関連するTransform IDが入力できる（ユーザー or システム管理者から）管理インターフェースを提供するべきである。 All implementations of IKEv2 MUST include a management facility that enables a user or system administrator to specify the suites that are acceptable for use with IKE. Upon receipt of a payload with a set of Transform IDs, the implementation MUST compare the transmitted Transform IDs against those locally configured via the management controls, to verify that the proposed suite is acceptable based on local policy. The implementation MUST reject SA proposals that are not authorized by these IKE suite controls. Note that cryptographic suites that MUST be implemented need not be configured as acceptable to local policy. IKEv2のすべての実装は、IKEで使用することを許容するsuiteを指定することをユーザーorシステム管理者に可能とする管理機能を含めること。Transform IDのsetのpayloadを受信すると、実装は、提案されたsuiteがローカルポリシーに基づき許可されるかを検証するため、management controlを経由してローカル設定と送信されたTransform IDを比較すること。実装は、これらのIKE suite制御によって、許容しないSAのproposalを拒絶すること。実装が必須なcryptographic suiteはローカルポリシーで許容されるように設定される必要はないことに注意せよ。 3.3.5. Transform Attributes Each transform in a Security Association payload may include attributes that modify or complete the specification of the transform. The set of valid attributes depends on the transform. Currently, only a single attribute type is defined the Key Length attribute is used by certain encryption transforms with variable- length keys (see below for details). Security Association payloadのTransformはtransformの仕様を設定/決定するAttributeを含めてよい。設定可能なAttributeはTransformによって異なる。現在一つのAttribute typeが定義されている。Key Length attributeは特定のEncryption Transfromの可変キー長を指定する(詳細は下記参照)。 The attributes are type/value pairs and are defined below. Attributes can have a value with a fixed two-octet length or a variable-length value. For the latter, the attribute is encoded as type/length/value. Attributeはtype/valueのペアで以下のように定義される。Attirubuteは2オクテットまたは可変長の値である。後者の場合、Attributeはtype/length/valueにエンコードされる。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Attribute Type | AF=0 Attribute Length | |F| | AF=1 Attribute Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AF=0 Attribute Value | | AF=1 Not Transmitted | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 Data Attributes o Attribute Format (AF) (1 bit) - Indicates whether the data attribute follows the Type/Length/Value (TLV) format or a shortened Type/Value (TV) format. If the AF bit is zero (0), then the attribute uses TLV format; if the AF bit is one (1), the TV format (with two-byte value) is used. AttibuteがType/Length/Value(TLV)か短縮形のType/Value(TV)かを示す。AFが0の場合、attributeはTLV形式を使用する。AFが1の場合、TV（2バイトvalue）を使用する。 o Attribute Type (15 bits) - Unique identifier for each type of attribute (see below). Attributeのtypeを識別する識別子。下記参照。 o Attribute Value (variable length) - Value of the attribute associated with the attribute type. If the AF bit is a zero (0), this field has a variable length defined by the Attribute Length field. If the AF bit is a one (1), the Attribute Value has a length of 2 octets. Attribute typeに関連するAttributeのvalue。AF bitが0の場合、このfieldはAttribute Length filedで定義された変数長をもつ。AFが1の場合、Attirbute Valueは2オクテットである。 The only currently defined attribute type (Key Length) is fixed length; the variable-length encoding specification is included only for future extensions. Attributes described as fixed length MUST NOT be encoded using the variable-length encoding unless that length exceeds two bytes. Variable-length attributes MUST NOT be encoded as fixed-length even if their value can fit into two octets. Note This is a change from IKEv1, where increased flexibility may have simplified the composer of messages but certainly complicated the parser. 現在、固定長のKey Lengthのみがattribute typeとして定義されている。可変長エンコーディングは今後の拡張のために含まれている。固定長として定義されるAttributeは2オクテットを超えない場合、可変長エンコーディングしないこと。可変長として定義されるAttirbuteは2オクテット内になる場合でも固定長エンコーディングしないこと。注意：これはIKEv1からの変更で、メッセージの構成に柔軟性はあるが、パースが複雑になる。 The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. 下記はRFC4306発行時のものである。以降に追加された値は[IKEV2IANA]参照。 Attribute Type Value Attribute Format ------------------------------------------------------------ Key Length (in bits) 14 TV Values 0-13 and 15-17 were used in a similar context in IKEv1, and should not be assigned except to matching values. 0～13、15～17は同じコンテキストとしてIKEv1で使用されるため、一致する値以外には割り当てないこと。 The Key Length attribute specifies the key length in bits (MUST use network byte order) for certain transforms as follows Key Length attributeは以下のように特定のTransformでkey lengthのbit長(ネットワークバイトオーダーを使用すること)を規定する。 o The Key Length attribute MUST NOT be used with transforms that use a fixed-length key. For example, this includes ENCR_DES, ENCR_IDEA, and all the Type 2 (Pseudorandom function) and Type 3 (Integrity Algorithm) transforms specified in this document. It is recommended that future Type 2 or 3 transforms do not use this attribute. Key Length attributeは固定長のkeyを使用するTransformに使用しないこと。例えば、ENCR_DES、ENCR_IDEAとType 2(Pseudorandom function)Transfrom、Type 3(Integrity Algorith) Transfromである。将来のType 2、Type3のTransformもこのAttributeを使用しないことを推奨する。 o Some transforms specify that the Key Length attribute MUST be always included (omitting the attribute is not allowed, and proposals not containing it MUST be rejected). For example, this includes ENCR_AES_CBC and ENCR_AES_CTR. いくつかのTransformはKey Length attribtuteを常に含む(Attributeが含まれないことが許容されない場合、Proposalは拒否されること)。例えば、ENCR_AES_CBC、ENCR_AES_CTRがある。 o Some transforms allow variable-length keys, but also specify a default key length if the attribute is not included. For example, these transforms include ENCR_RC5 and ENCR_BLOWFISH. いくつかのTransformは可変長キーを許可し、attributeを含まない場合、デフォルトのkey lengthを用いる。例えば、ENCR_RC5、ENCR_BLIWFISHがある。 Implementation note To further interoperability and to support upgrading endpoints independently, implementers of this protocol SHOULD accept values that they deem to supply greater security. For instance, if a peer is configured to accept a variable-length cipher with a key length of X bits and is offered that cipher with a larger key length, the implementation SHOULD accept the offer if it supports use of the longer key. Support for this capability allows a responder to express a concept of at least a certain level of security -- a key length of _at least_ X bits for cipher Y . However, as the attribute is always returned unchanged (see the next section), an initiator willing to accept multiple key lengths has to include multiple transforms with the same Transform Type, each with a different Key Length attribute. 実装上の注意：相互運用性の向上およびエンドポイントのアップグレードを提供するため、プロトコルの実装では高いセキュリティを提供するための値を許容すること。例えば、peerがkey length X bitの可変長暗号を許容するように設定されていて、より長いキー長を要求された場合、長いキーをサポートする場合は、実装はその要求を許容するべきである。この機能の提供はresponderが最低限のsecurity levelを表すことを可能にする（暗号Yのkey lengthは最低でもX bit）。しかし、attributeは変更されずに返されるため（次のセクション参照）、複数のkey lengthを受け入れるinitiatorは、同じTransfomr Type、異なるKey Length attributeの複数のtransformを含める。 3.3.6. Attribute Negotiation During Security Association negotiation initiators present offers to responders. Responders MUST select a single complete set of parameters from the offers (or reject all offers if none are acceptable). If there are multiple proposals, the responder MUST choose a single proposal. If the selected proposal has multiple transforms with the same type, the responder MUST choose a single one. Any attributes of a selected transform MUST be returned unmodified. The initiator of an exchange MUST check that the accepted offer is consistent with one of its proposals, and if not MUST terminate the exchange. Security Associationのネゴシエーション中、initiatorはresponderに要求する際。Responderは要求から、パラメータの一つを選択する(すべての要求を許容できない場合、拒否する)。複数のproposalがある場合、responderは一つのproposalを選択すること。選択されたproposalが同じtypeのtransformを複数もつ場合、responderは一つを選択すること。選択したいずれかのattibuteを変更せずに応答すること。exchangeのinitiatorは応答がinitiatorのproposalと一致しているか確認すること。一致していない場合、exchangeを終了する。 If the responder receives a proposal that contains a Transform Type it does not understand, or a proposal that is missing a mandatory Transform Type, it MUST consider this proposal unacceptable; however, other proposals in the same SA payload are processed as usual. Similarly, if the responder receives a transform that it does not understand, or one that contains a Transform Attribute it does not understand, it MUST consider this transform unacceptable; other transforms with the same Transform Type are processed as usual. This allows new Transform Types and Transform Attributes to be defined in the future. responderが解釈できないTransfrom Type、必須のTransform TypeのないProposalを受信した場合、Proposalは許容しないこと。ただし、同じSA payloadの他のProposalは通常通り処理される。同様にresponderは解釈できないTransform、解釈できないTransform Attributeを含むtrasnfromについても許容しないこと。ただし、同じTransform Typeをもつ他のTransformは通常通り処理されること。これは、将来、新しいTransform Type、Transform Attributeが定義されることを許容する。 Negotiating Diffie-Hellman groups presents some special challenges. SA offers include proposed attributes and a Diffie-Hellman public number (KE) in the same message. If in the initial exchange the initiator offers to use one of several Diffie-Hellman groups, it SHOULD pick the one the responder is most likely to accept and include a KE corresponding to that group. If the responder selects a proposal using a different Diffie-Hellman group (other than NONE), the responder will indicate the correct group in the response and the initiator SHOULD pick an element of that group for its KE value when retrying the first message. It SHOULD, however, continue to propose its full supported set of groups in order to prevent a man-in-the- middle downgrade attack. If one of the proposals offered is for the Diffie-Hellman group of NONE, and the responder selects that Diffie- Hellman group, then it MUST ignore the initiator s KE payload and omit the KE payload from the response. Diffie-Hellman groupのネゴシエーションにはいくつかの特別な課題がある。SAの要求は同じメッセージにproposal attributeとDiffie-Hellman public number(KE)を含む。initial exchangeでinitiatorが複数のDiffie-Hellman groupから一つの使用を要求する場合、initiatorはresponderがそれを選ぶようにKEに対応するgroupを含める。responderが異なるDiffie-Hellman group (NONEを除く)を選択する場合、responderは適切なgroupをresponseで示し、initiatorはそのgroupをKEに選択し、最初のメッセージを再試行する。ただし、initiatorはman-in-the-middle downgrade attackを防ぐためにgroupのフルセットをproposeし続けること。要求された一つがDiffie-Hellman group NONEであり、responderがそのDiffie-Hellman groupを選択した場合、responderはinitiatorのKE payloadを無視し、initiatorは応答のKE paylaodを切り捨てること。 3.4. Key Exchange Payload The Key Exchange payload, denoted KE in this document, is used to exchange Diffie-Hellman public numbers as part of a Diffie-Hellman key exchange. The Key Exchange payload consists of the IKE generic payload header followed by the Diffie-Hellman public value itself. Key Exchange payloadはKEと表記され、Diffie-Hellman鍵交換の一部として、Diffie-Hellman public numberを交換するために使用される。Key Exchange paloadはIKE generic payloadとDiffie-Hellman public valueで構成される。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diffie-Hellman Group Num | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Key Exchange Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10 Key Exchange Payload Format A Key Exchange payload is constructed by copying one s Diffie-Hellman public value into the Key Exchange Data portion of the payload. The length of the Diffie-Hellman public value for modular exponentiation group (MODP) groups MUST be equal to the length of the prime modulus over which the exponentiation was performed, prepending zero bits to the value if necessary. Key Exchange payloadはpayloadのKey Exchange DataにDiffie-Hellman public valueを設定する。(modular exponentiation group)MODP groupのDiffie-Hellman public valueの値はprime module(素数)と同じ長さであること。必要であれば0で埋めること。 The Diffie-Hellman Group Num identifies the Diffie-Hellman group in which the Key Exchange Data was computed (see Section 3.3.2). This Diffie-Hellman Group Num MUST match a Diffie-Hellman group specified in a proposal in the SA payload that is sent in the same message, and SHOULD match the Diffie-Hellman group in the first group in the first proposal, if such exists. If none of the proposals in that SA payload specifies a Diffie-Hellman group, the KE payload MUST NOT be present. If the selected proposal uses a different Diffie-Hellman group (other than NONE), the message MUST be rejected with a Notify payload of type INVALID_KE_PAYLOAD. See also Sections 1.2 and 2.7. Diffie-Hellman Group NumはKey Exchange Dataが算出されるDiffie-Hellman groupを識別する（Section 3.3.2参照）。Diffie-Hellman Group Numは同じメッセージで送信されたSA payloadのproposalで規定されたDiffie-Hellman groupと一致すること。さらに、最初proposalと一致すること。SA payloadでDiffie-Hellman groupがporoposalされない場合、KE payloadを提供しないこと。選択されたproposalが異なるdifferent Diffie-Hellman group (NONE以外)の場合、messageはINVALID_KE_PAYLOADでrejectすること。Section 1.2と2.7参照。 The payload type for the Key Exchange payload is thirty-four (34). Key Exchange payloadのpayload typeは34である。 3.5. Identification Payloads The Identification payloads, denoted IDi and IDr in this document, allow peers to assert an identity to one another. This identity may be used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions. When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match the address in the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. The contents of IDi/IDr are used purely to fetch the policy and authentication data related to the other party. Identification PayloadはIDi、IDrと表現され、peerが相互に他方にIDを通知するために使用する。このIDはpolicy検索に使用できるが、CERT payloadとマッチする必要はない。両方のfieldはアクセス制御の決定をするために実装で使用される。IDi/IDr paylaodでID_IPV4_ADDR/ID_IPV6_ADDR identity typesを使用する場合、IKEv2ではIKEv2のIP headerアドレスまたはTSi/TSr paylaodと一致することを必要としない。IDi/IDrは相手のpolicyと認証データを照会するために使用される。 NOTE In IKEv1, two ID payloads were used in each direction to hold Traffic Selector (TS) information for data passing over the SA. In IKEv2, this information is carried in TS payloads (see Section 3.13). NOTE IKEv1では2つのID payloadが各方向でSA上でデータを通過させるためのTraffic Selector情報を保持するために使われる。IKEv2ではこの情報はTS payloadで設定される(Section 3.13)。 The Peer Authorization Database (PAD) as described in RFC 4301 [IPSECARCH] describes the use of the ID payload in IKEv2 and provides a formal model for the binding of identity to policy in addition to providing services that deal more specifically with the details of policy enforcement. The PAD is intended to provide a link between the SPD and the IKE Security Association management. See Section 4.4.3 of RFC 4301 for more details. RFC 4301[IPSECARCH]にあるように、Peer Authorization Database(PAD)はIKEのID payloadの使用方法とpolicyの適用方法を具体化するための形式的なモデルを提供する。PADはSPDとIKE Security Association managementとのリンクを提供する。詳細はRFC 4301 Section 4.4.3を参照。 The Identification payload consists of the IKE generic payload header followed by identification fields as follows Identification payloadはIKE generic paylaod headerと下記のidentification fieldで構成される。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Identification Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 Identification Payload Format o ID Type (1 octet) - Specifies the type of Identification being used. Identificationのtypeを規定する。 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 0を設定し、受信者は無視すること。 o Identification Data (variable length) - Value, as indicated by the Identification Type. The length of the Identification Data is computed from the size in the ID payload header. Identification Typeで規定される値。Identification DataのlengthはID paylaod header内のsizeから計算される。 The payload types for the Identification payload are thirty-five (35) for IDi and thirty-six (36) for IDr. Identificatin paylaodのpayload typeはIDiが35、IDrが36である。 The following table lists the assigned semantics for the Identification Type field. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. 下記の表はIdentification Type filedに割り当てられたセマンティクスである。最新の情報は[IKEV2IANA]参照。下記の表はRFC4306発行時のものである。その他の値が追加される可能性もある。最新の情報は[IKEV2IANA]参照。 ID Type Value ------------------------------------------------------------------- ID_IPV4_ADDR 1 A single four (4) octet IPv4 address. 4オクテットのIPv4アドレス。 ID_FQDN 2 A fully-qualified domain name string. An example of an ID_FQDN is example.com . The string MUST NOT contain any terminators (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; for an internationalized domain name , the syntax is as defined in [IDNA], for example xn--tmonesimerkki-bfbb.example.net . FQDMの文字列。ID_FQDNの例は example.com である。文字列はNULL、CRなどで終端しないこと。ID_FQDNの文字はすべてASCIIである。[IDNA]で定義されたinternationalized domain nameで例えばxn--tmonesimerkki-bfbb.example.netである。 ID_RFC822_ADDR 3 A fully-qualified RFC 822 email address string. An example of a ID_RFC822_ADDR is jsmith@example.com . The string MUST NOT contain any terminators. Because of [EAI], implementations would be wise to treat this field as UTF-8 encoded text, not as pure ASCII. 完全修飾のRFC 822のemail addressの文字列。ID_RFC822_ADDRの例はjsmith@example.comである。文字列には終端を含まないこと。[EAI]により実装ではASCIIではなくUTF-8 encoded textとして扱ったほうがよい。 ID_IPV6_ADDR 5 A single sixteen (16) octet IPv6 address. 16オクテットのIPv6アドレス。 ID_DER_ASN1_DN 9 The binary Distinguished Encoding Rules (DER) encoding of an ASN.1 X.500 Distinguished Name [PKIX]. ASN.1 X.500[PKIX]のバイナリDER encoding。 ID_DER_ASN1_GN 10 The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX]. ASN.1 X.509[PKIX]のバイナリDER encoding。 ID_KEY_ID 11 An opaque octet stream that may be used to pass vendor- specific information necessary to do certain proprietary types of identification. オクテット列でベンダー仕様の独自のID typeを渡すために使用してよい。 Two implementations will interoperate only if each can generate a type of ID acceptable to the other. To assure maximum interoperability, implementations MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these four types. Implementations SHOULD be capable of generating and accepting all of these types. IPv6-capable implementations MUST additionally be configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable to send only ID_IPV6_ADDR instead of ID_IPV4_ADDR for IP addresses. お互いが他方が許容できるIDタイプを生成できる場合、2つの実装（2種類のID）が相互運用する。最大の相互運用性を保証するためには、実装はID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_IDの少なくとも一つを送信し、4つのどのタイプでも許容できることが可能であること。実装は全てのタイプを生成でき、許容できること。IPv6に対応した実装ではID_IPV6_ADDRを許容できること。IPv6のみの実装ではID_IPV4_ADDRの代わりにID_IPV6_ADDRのみを送信してもよい。 EAP [EAP] does not mandate the use of any particular type of identifier, but often EAP is used with Network Access Identifiers (NAIs) defined in [NAI]. Although NAIs look a bit like email addresses (e.g., joe@example.com ), the syntax is not exactly the same as the syntax of email address in [MAILFORMAT]. For those NAIs that include the realm component, the ID_RFC822_ADDR identification type SHOULD be used. Responder implementations should not attempt to verify that the contents actually conform to the exact syntax given in [MAILFORMAT], but instead should accept any reasonable-looking NAI. For NAIs that do not include the realm component, the ID_KEY_ID identification type SHOULD be used. EAPは特定のIDタイプを指定しないが、たいてい[NAI]で定義されたNetwork Access Identifiers(NAI)が使用される。NAIはemail addressのように見えるが（例：joe@example.com）、構文は[MAILFORMAT]とは厳密には同じではない。realmを含むNAIはID_RFC822_ADDRのIDタイプを使用すること。responderの実装は、[MAILFORMAT]によるチェックではなく、NAIの定義によりチェックすること。NAIがrealmを含まない場合、ID_KEY_ID identification typeを使用すること。 3.6. Certificate Payload The Certificate payload, denoted CERT in this document, provides a means to transport certificates or other authentication-related information via IKE. Certificate payloads SHOULD be included in an exchange if certificates are available to the sender. The Hash and URL formats of the Certificate payloads should be used in case the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the term Certificate payload is somewhat misleading, because not all authentication mechanisms use certificates and data other than certificates may be passed in this payload. Certificate payload はCERTと表記され、IKEによる証明書や認証関連情報の転送を提供する。証明書を送信者が利用する場合、Certificate payloadがexchangeに含まれること。peerがHTTP_CERT_LOOKUP_SUPPORTED Notify payloadを使用し、この情報を取得する能力を通知してから、Certificate payloadのHash and URL formatが使用されること。 Certificate payload は誤解を招くのに注意せよ。なぜなら、すべての認証メカニズムが証明書を使用するとは限らず、証明書以外のデータも送信されるため。 The Certificate payload is defined as follows Certificate payload は下記のように定義される。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert Encoding | | +-+-+-+-+-+-+-+-+ | ~ Certificate Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12 Certificate Payload Format o Certificate Encoding (1 octet) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. このfieldはCertificate Data fieldに含まれる証明書または証明書関連情報のtypeを示す。下記の値および以降に追加されてた値が設定される。下記はRFC4306発行時のものである。以降に追加された値は[IKEV2IANA]参照。 Certificate Encoding Value ---------------------------------------------------- PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED PGP Certificate 2 UNSPECIFIED DNS Signed Key 3 UNSPECIFIED X.509 Certificate - Signature 4 Kerberos Token 6 UNSPECIFIED Certificate Revocation List (CRL) 7 Authority Revocation List (ARL) 8 UNSPECIFIED SPKI Certificate 9 UNSPECIFIED X.509 Certificate - Attribute 10 UNSPECIFIED Raw RSA Key 11 Hash and URL of X.509 certificate 12 Hash and URL of X.509 bundle 13 o Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Encoding field. 証明書データのencoding。証明書のtypeはCertificate Encoding fieldで示される。 The payload type for the Certificate payload is thirty-seven (37). Certificate payloadのpayload typeは37である。 Specific syntax for some of the certificate type codes above is not defined in this document. The types whose syntax is defined in this document are 上記の証明書 type codeのすべてのシンタックスは本ドキュメントでは規定しない。本ドキュメントでは下記のtypeのシンタックスを定義する。 o X.509 Certificate - Signature contains a DER-encoded X.509 certificate whose public key is used to validate the sender s AUTH payload. Note that with this encoding, if a chain of certificates needs to be sent, multiple CERT payloads are used, only the first of which holds the public key used to validate the sender s AUTH payload. X.509 Certificate - Signature は、送信者のAUTH payloadを検証するために使用されるpublic keyの DER-encoded X.509証明書が含まれる。エンコーディングは、証明書チェーンを送信する必要がある場合、複数のCERT payloadが使用され、最初のpayloadだけ送信者のAUTH payloadを検証するために使用されるpublic keyを含む。 o Certificate Revocation List contains a DER-encoded X.509 certificate revocation list. Certificate Revocation List はDER-encoded X.509の証明書の失効リストが含まれる。 o Raw RSA Key contains a PKCS #1 encoded RSA key, that is, a DER- encoded RSAPublicKey structure (see [RSA] and [PKCS1]). Raw RSA Key はPKCS #1 encoded RSA keyつまり、DER-encoded RSAPublicKey structureが含まれる（[RSA]、[PKCS1]参照）。 o Hash and URL encodings allow IKE messages to remain short by replacing long data structures with a 20-octet SHA-1 hash (see [SHA]) of the replaced value followed by a variable-length URL that resolves to the DER-encoded data structure itself. This improves efficiency when the endpoints have certificate data cached and makes IKE less subject to DoS attacks that become easier to mount when IKE messages are large enough to require IP fragmentation [DOSUDPPROT]. Hash and URL encodingにより、長いdata structuresをDER-encoded data structureに対応する可変長URLに続く20-octet SHA-1 hashに置き換えることで、IKE messageを短くすることができる。これにより、証明書データがキャッシュされているときの効率化と、IP fragmentを利用したDoS攻撃の防止になる[DOSUDPPROT]。 The Hash and URL of a bundle type uses the following ASN.1 definition for the X.509 bundle Hash and URL of a bundle typeは下記のX.509 bundleのASN.1定義を使用する。 CertBundle { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cert-bundle(34) } DEFINITIONS EXPLICIT TAGS = BEGIN IMPORTS Certificate, CertificateList FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } ; CertificateOrCRL = CHOICE { cert [0] Certificate, crl [1] CertificateList } CertificateBundle = SEQUENCE OF CertificateOrCRL END Implementations MUST be capable of being configured to send and accept up to four X.509 certificates in support of authentication, and also MUST be capable of being configured to send and accept the Hash and URL format (with HTTP URLs). Implementations SHOULD be capable of being configured to send and accept Raw RSA keys. If multiple certificates are sent, the first certificate MUST contain the public key used to sign the AUTH payload. The other certificates may be sent in any order. 実装は認証をサポートする4つのX.509証明書の送受信が構成できること。また、Hash and URL formatの送受信が構成できること。実装はRaw RSA keyの送受信を構成できること。複数の証明書を送信する場合、最初の証明書はAUTH payloadの署名に使用するpublic keyを含めること。その他の証明書は任意の順番で送信してよい。 Implementations MUST support the HTTP [HTTP] method for hash-and-URL lookup. The behavior of other URL methods [URLS] is not currently specified, and such methods SHOULD NOT be used in the absence of a document specifying them. 実装は、hash-and-URL lookupのためのHTTP methodをサポートすること。他のURL method[URLS]は現在規定されず、そのようなmethodはそれらを規定するドキュメントが存在しない場合に使用しないこと。 3.7. Certificate Request Payload The Certificate Request payload, denoted CERTREQ in this document, provides a means to request preferred certificates via IKE and can appear in the IKE_INIT_SA response and/or the IKE_AUTH request. Certificate Request payloads MAY be included in an exchange when the sender needs to get the certificate of the receiver. Certificate Request payloadはCERTREQと表記され、IKEで証明書を要求する手段を提供し、IKE_INIT_SA responseとIKE_AUTH requestで送信される。Certificate Request payloadは、送信者が受信者の証明書を取得する必要がある場合、Certificate Request payloadがexchangeに含まれてよい。 The Certificate Request payload is defined as follows Certificate Request payloadは下記のように定義される。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert Encoding | | +-+-+-+-+-+-+-+-+ | ~ Certification Authority ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13 Certificate Request Payload Format o Certificate Encoding (1 octet) - Contains an encoding of the type or format of certificate requested. Values are listed in Section 3.6. 要求された証明書の種類、encoding typeが含まれる。値のリストはSection 3.6参照。 o Certification Authority (variable length) - Contains an encoding of an acceptable certification authority for the type of certificate requested. 要求された証明書のタイプの認証局のencodingが含まれる。 The payload type for the Certificate Request payload is thirty-eight (38). Certificate Request payloadのpaylaod typeは38である。 The Certificate Encoding field has the same values as those defined in Section 3.6. The Certification Authority field contains an indicator of trusted authorities for this certificate type. The Certification Authority value is a concatenated list of SHA-1 hashes of the public keys of trusted Certification Authorities (CAs). Each is encoded as the SHA-1 hash of the Subject Public Key Info element (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. The 20-octet hashes are concatenated and included with no other formatting. Certificate Encoding fieldはSection 3.6の定義と同じ値である。Certification Authority fieldは証明書typeの認証局のindicatorが含まれる。Certification Authority valueは、認証局(CA)のpublic keyのSHA-1ハッシュの連結リストである。それぞれが、Subject Public Key Info element(see section 4.1.2.7 of [PKIX])のSHA-1ハッシュとしてそれぞれのTrust Anchor certificateからencodeされる。20-octetのハッシュには他のフォーマットが連結されず、含まれない。 The contents of the Certification Authority field are defined only for X.509 certificates, which are types 4, 12, and 13. Other values SHOULD NOT be used until Standards-Track specifications that specify their use are published. Certification Authority fieldの内容はX.509証明書のみ定義され、typeは4、12、13である。他の値は他の値を規定する仕様が公開されるまで使用しないこと。 Kaufman, et al. Standards Track [Page 93] RFC 5996 IKEv2bis September 2010 Note that the term Certificate Request is somewhat misleading, in that values other than certificates are defined in a Certificate payload and requests for those values can be present in a Certificate Request payload. The syntax of the Certificate Request payload in such cases is not defined in this document. Certificate Request は誤解を招くことに注意せよ。 Certificate payloadに証明書以外の値が定義され、Certificate Request payloadによりそれらの値が要求される場合がある。それらの場合におけるCertificate Request payloadのsyntaxはこのドキュメントでは定義されない。 The Certificate Request payload is processed by inspecting the Cert Encoding field to determine whether the processor has any certificates of this type. If so, the Certification Authority field is inspected to determine if the processor has any certificates that can be validated up to one of the specified certification authorities. This can be a chain of certificates. Certificate Request payloadはprocessorがどのタイプの証明書を持っているかを Cert Encoding fieldを検証して処理する。 Certification Authority fieldは認証局を検証できる証明書を持っているか判断するために検証される。これは証明書チェーンをすることができる。 If an end-entity certificate exists that satisfies the criteria specified in the CERTREQ, a certificate or certificate chain SHOULD be sent back to the certificate requestor if the recipient of the CERTREQ CERTREQの条件を満たすend-entity証明書が存在する場合、CERTREQの受信者は証明書または証明書チェーンを証明書の要求者に送信すること。 o is configured to use certificate authentication, 証明書認証を使用することが設定されている。 o is allowed to send a CERT payload, CERT payloadの送信が許容される。 o has matching CA trust policy governing the current negotiation, and ネゴシエーション中のCA trust policyに一致する。 o has at least one time-wise and usage-appropriate end-entity certificate chaining to a CA provided in the CERTREQ. CERTREQ内のCAに提供された使用可能なend-entity証明書チェーンがある。 Certificate revocation checking must be considered during the chaining process used to select a certificate. Note that even if two peers are configured to use two different CAs, cross-certification relationships should be supported by appropriate selection logic. 証明書の失効チェックは証明書を選択するために使用されるチェーン処理中に考慮されること。2つのpeerが2つの異なるCAを使うように構成されている場合、cross-certification relationshipがselection logicによってサポートされることに注意せよ。 The intent is not to prevent communication through the strict adherence of selection of a certificate based on CERTREQ, when an alternate certificate could be selected by the sender that would still enable the recipient to successfully validate and trust it through trust conveyed by cross-certification, CRLs, or other out-of- band configured means. Thus, the processing of a CERTREQ should be seen as a suggestion for a certificate to select, not a mandated one. If no certificates exist, then the CERTREQ is ignored. This is not an error condition of the protocol. There may be cases where there is a preferred CA sent in the CERTREQ, but an alternate might be acceptable (perhaps after prompting a human operator). CERTREQの処理は、証明書の取得命令ではなく選択の提案としてみなされる。証明書が存在しない場合、CERTREQは無視される。これはprotocolエラー状態ではない。CERTREQのCAよりよいCAがあるが、代替が許容される場合がある（オペレーターが指定した場合）。 The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certificates based on an HTTP-based URL (and hence presumably would prefer to receive certificate specifications in that format). HTTP_CERT_LOOKUP_SUPPORTED notificationがCERTREQ payloadを含む任意のメッセージに含まれてよく、送信者がHTTP-based URLによる証明書のlook upができることを示す（つまり、その形式の証明書を受信することを望んでいる）。 3.8. Authentication Payload The Authentication payload, denoted AUTH in this document, contains data used for authentication purposes. The syntax of the Authentication data varies according to the Auth Method as specified below. Authentication payloadはAUTHと表記され、認証に使用されるデータが含まれる。Authentication dataの構文は下記に示すように認証方法によって異なる。 The Authentication payload is defined as follows Authentication payloadは下記のように定義される。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Method | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Authentication Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14 Authentication Payload Format o Auth Method (1 octet) - Specifies the method of authentication used. The types of signatures are listed here. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. 使用される認証方法を規定する。署名の種類は下記の通り。この値はRFC4306のものである。最新の値は[IKEV2IANA]を参照。 Mechanism Value ----------------------------------------------------------------- RSA Digital Signature 1 Computed as specified in Section 2.15 using an RSA private key with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1] (implementers should note that IKEv1 used a different method for RSA signatures). To promote interoperability, implementations that support this type SHOULD support signatures that use SHA-1 as the hash function and SHOULD use SHA-1 as the default hash function when generating signatures. Implementations can use the certificates received from a given peer as a hint for selecting a mutually understood hash function for the AUTH payload signature. [PKCS1]で規定されたRSASSA-PKCS1-v1_5 signature schemeのRSA秘密鍵を使用してSection 2.15で規定された方法で計算される。（実装は、IKEv1ではRSA signatureのために別のmethodを使用したことに注意せよ。） 相互運用性の保証のため、このタイプの署名をサポートする実装では、ハッシュ関数としてSHA-1を使用してsignatureを生成するときはデフォルトのハッシュ関数としてSHA-1を使用するsignatureをサポートすること。実装は、相互にAUTH payload署名のハッシュ関数を特定し、選択するためにpeerから受信した証明書を使用できる。 Note, however, that the hash algorithm used in the AUTH payload signature doesn t have to be the same as any hash algorithm(s) used in the certificate(s). AUTH paylaodのsignatureに使用されるハッシュアルゴリズムは証明書で使用されるハッシュアルゴリズムと同じである必要はない。 Shared Key Message Integrity Code 2 Computed as specified in Section 2.15 using the shared key associated with the identity in the ID payload and the negotiated PRF. ID payloadのidentityと関連付けられるshared keyとネゴシエーションされたPRFを使用し、Section 2.15で規定された方法で計算される。 DSS Digital Signature 3 Computed as specified in Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 hash. SHA-1ハッシュのDSS秘密鍵を使用してSection 2.15の方法で計算される。([DSS]参照) o Authentication Data (variable length) - see Section 2.15. Section 2.15参照。 The payload type for the Authentication payload is thirty-nine (39). Authentication payloadのpayload typeは39である。 3.9. Nonce Payload The Nonce payload, denoted as Ni and Nr in this document for the initiator s and responder s nonce, respectively, contains random data used to guarantee liveness during an exchange and protect against replay attacks. Nonce payloadはNi/Nrと表現され、replay攻撃に対する保護のためと、echangeの間の生存性を保証するためのランダムデータを含む。 The Nonce payload is defined as follows Nonce payloadは下記のように定義される。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Nonce Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15 Nonce Payload Format o Nonce Data (variable length) - Contains the random data generated by the transmitting entity. 送信エンティティによって生成されたランダムデータが含まれる。 The payload type for the Nonce payload is forty (40). Nonce payloadのpayload typeは40である。 The size of the Nonce Data MUST be between 16 and 256 octets, inclusive. Nonce values MUST NOT be reused. Nonce Dataは16～256オクテットであること。Nonce valueは再利用しないこと。 3.10. Notify Payload The Notify payload, denoted N in this document, is used to transmit informational data, such as error conditions and state transitions, to an IKE peer. A Notify payload may appear in a response message (usually specifying why a request was rejected), in an INFORMATIONAL Exchange (to report an error not in an IKE request), or in any other message to indicate sender capabilities or to modify the meaning of the request. Notify payload（Nと表記される）はIKE peerにエラー状態や状態遷移などの情報データを送信するために使用される。Notify payloadは応答メッセージ(通常はrequestを拒否した理由を示す)、INFORMATIONAL Exchange(IKE requestでないエラーの報告)、送信者の機能、requestの意味(meaning)の変更に使用される。 The Notify payload is defined as follows Notify payloadは下記のように定義される。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol ID | SPI Size | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Security Parameter Index (SPI) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Notification Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16 Notify Payload Format o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the type of that SA. For notifications concerning Child SAs, this field MUST contain either (2) to indicate AH or (3) to indicate ESP. Of the notifications defined in this document, the SPI is included only with INVALID_SELECTORS and REKEY_SA. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt. このnotificationがSPI fieldで示されるSPIをもつ既存のSAに関係する場合、このfiledはSAの種類を示す。Child SAに関するnotificationの場合、このfiledはAH(2)かESP(3)であること。このドキュメントで定義されたnotificationの中で、SPIはINVALID_SELECTORS、REKEY_SAにのみ含まれる。SPI filedが空の場合、このfiledは0で送信され、受信者はそれを無視すること。 o SPI Size (1 octet) - Length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE SA, the SPI Size MUST be zero and the field must be empty. IPsec protocol IDで定義されたSPIのオクテット長。SPIが有効でない場合は0。IKE SAに関するnotificationは、SPI Sizeは0であり、field（SPI field variable lengthのこと）は空であること。 o Notify Message Type (2 octets) - Specifies the type of notification message. notification messageのタイプを指定する。 o SPI (variable length) - Security Parameter Index. Security Parameter Index(SPI)。 o Notification Data (variable length) - Status or error data transmitted in addition to the Notify Message Type. Values for this field are type specific (see below). Statusまたはerror dataがNotify Message Typeに加えて送信される。このfieldの値はtypeによって決まる(下記参照)。 The payload type for the Notify payload is forty-one (41). Notify payloadのpaylaod typeは41である。
https://w.atwiki.jp/portal2_mod/pages/16.html
Coop用MODの紹介です。 ※現在相方がおらず、追加出来ないので一緒にやって頂ける方は、雑談板にコメントよろしくです！ 編集用↓(コピーして使って下さい。) 名前 サイズ 部屋数 時間 難易度 オススメ #ref error ：ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (画像URL) 説明 タイトル サイズ 部屋数 時間 難易度 オススメ 説明 cherish 1.31MB 1 20分 3 3 気軽に出来る難易度 ボリューム。特に難しい仕掛け等はないので始めたての人はどうぞ！ chickentest 1.21MB 1 20分 3 3 #ref error ：画像を取得できませんでした。しばらく時間を置いてから再度お試しください。 何度か死んで、通り抜けれるコツをつかもう。笑 帰り道にはコツがあり、気づければ楽になる。 Discovery 7.78MB 6 1時間 4 5 #ref error ：画像を取得できませんでした。しばらく時間を置いてから再度お試しください。 テストチェンバー3つ各2マップで構成されている。coopのアートセラピー中盤～後半にかけてと同じくらいの難易度。ボリュームもある。 Fast Bridge 2 9.33MB 40分 5 4 #ref error ：画像を取得できませんでした。しばらく時間を置いてから再度お試しください。 各部屋難易度少し高め。後半の縦にブリッジが出ていて、向こう側にスイッチがある場所は、飛距離を出すために落下する距離を伸ばす事を考えよう。 Impetuosity 34.97MB 大部屋1つ+4チェンバー分 3～4時間前後 5↑ 5 #ref error ：画像を取得できませんでした。しばらく時間を置いてから再度お試しください。 このMODの説明文にある通り4時間くらいかかる。タイミング重視される部分が結構あるのでVCで連携とれてないとかなりきついかもしれない。coop難しいのをお探しの方挑戦どうぞ！因みに、bspファイルが2つあるが、頭にhalf～が付いてるファイルは英文を読む限り少しクリアしてあるみたいなので、フルでプレイしたい方は、そうじゃない方を選ぶといい。 Redirecting Redirection 5.65MB 1 30分 5 4 1部屋しかないが、かなりの難易度。 The Amazing Race サイズ 部屋数 72.9MB 4 3~5 #ref error ：画像を取得できませんでした。しばらく時間を置いてから再度お試しください。 協力プレイではなくレース(2人別々で同じコースをやる)の点に注意。ちょこちょこテクニックがいる場面が出てくるので、ある程度なれた2人でやると盛り上がるかもしれない。